Quick answer: no. But there are idiosyncracies with it that should make you think whether to choose it as your mail server or not:
No email server (that I know of) is perfect. Postfix is currently the one I'm using by default on new setups. The main reason being it has a 'regular' linux setup (regular /etc/init.d entries, regular name=value config files, etc).
For a typical qmail installation with Plesk, you can monitor the logs with the following command:
tail -f /usr/local/psa/var/log/maillog
Qmail can send out an email when an email arrives for someone it does not know about. (e.g. This is the default setup in Plesk's qmail setup).
Typically these emails are from spammers. And the spammers will not have provided their real address.
So the 'bounce' email will trigger an error message reply and qmail will queue up the bounce email for delivery later on. Good luck with that qmail :)
You can change the 'bounce saying ..blah..' behavior to one where the email server just ignores any email arriving for an unknown user.
Just edit /var/qmail/mailnames/$DOMAIN/.qmail-default and replace its contents with:
|true
i.e. a pipe (|) symbol and true (the command true which runs, does nothing and returns a success code). If there is no "/var/qmail/mailnames" directory, try "/var/qmail/alias".
To change all domains so they do not send bounces, run (on systems with Plesk):
find /var/qmail/mailnames/ | grep .qmail-default | xargs replace "|bouncesaying 'This address no longer accepts mail.'" '|/bin/true' --
Or the (slightly more agressive):
for i in $(find /var/qmail/mailnames/ | grep .qmail-default); do
echo '|/bin/true' > $i
done
This setup will send messages to the void. There will be no confirmation or feedback after ignoring this message. If you want to keep track of those messages being ignored, use this instead to send notifications to syslog:
for i in $(find /var/qmail/mailnames/ | grep .qmail-default); do
echo "|$(which logger)" '-p mail.info -t qmail "ignoring mail: invalid destination - <\$SENDER> <\$RECIPIENT>"' > $i
done
/var/qmail/bin/qmail-showctl will show info about qmail setup.
/var/qmail/bin/qmail-qstat will show what is in the mail queue.
# to clear the queue
{
/etc/init.d/qmail stop
cd /var/qmail/queue
rm -rf info intd local mess remote todo
mkdir mess
for i in `seq 0 22`; do
mkdir mess/$i
done
cp -r mess info
cp -r mess intd
cp -r mess local
cp -r mess remote
cp -r mess todo
chmod -R 750 mess todo
chown -R qmailq:qmail mess todo
chmod -R 700 info intd local remote
chown -R qmailq:qmail intd
chown -R qmails:qmail info local remote
/etc/init.d/qmail start
}
qmHandle is a handy tool for manipulating the qmail queue, and for gathering some basic statistics about it.
To install it (to your current directory) run:
wget -O - "http://easynews.dl.sourceforge.net/sourceforge/qmhandle/qmhandle-1.3.2.tar.gz" | tar xzf -
If you're using qmHandle with Plesk's qmail, try an older version that doesn't attempt to stop qmail with 'svc':
wget -O - "http://easynews.dl.sourceforge.net/sourceforge/qmhandle/qmhandle-1.2.0.tar.gz" | tar xzf -
If you have a lot of bounce notices sitting in your queue, try running:
./qmHandle -S'failure notice'
The -S means ' delete all messages that have/contain text as Subject'.
Need to track who sent a particular email from your server? e.g. if a user account is compromised and you need to see which user account?
The email will have headers like:
Received: (qmail 13711 invoked from network); 26 Jun 2007 02:55:46 -0000
Received: from hpbizway.com.ar (HELO User) (1.2.3.4)
by example.com with SMTP; 26 Jun 2007 02:55:46 -0000
The 'invoked from network' means the email was received from an external host (e.g. it was not send from a program like apache on your server itself).
The IP that sent the email was 1.2.3.4
So run:
grep 1.2.3.4 /var/log/messages
(Use whatever IP you need to there).
And you will find which user that IP was using. e.g.
/var/log/messages:Jun 26 16:17:35 example smtp_auth: SMTP connect from unknown@hpbizway.com.ar [1.2.3.4]
/var/log/messages:Jun 26 16:17:35 example smtp_auth: smtp_auth: SMTP user claudia
In this case it is the 'claudia' user. And a suitable follow up would be to, say, change the password on that user account.
Do you have lots of /var/qmail/bin/qmail-smtpd processes? All using lots of CPU?
Are you missing files named /var/qmail/control/dh512.pem and /var/qmail/control/dh1024.pem?
Do you have /var/qmail/control/dhparams512.pem and /var/qmail/control/dhparams1024.pem?
In this case it may be that your qmail process is generating a ssl key for each connection, rather than using a pre-prepared one.
The fix is to run:
cp /var/qmail/control/dhparams512.pem /var/qmail/control/dh512.pem
cp /var/qmail/control/dhparams1024.pem /var/qmail/control/dh1024.pem
Then you may also need to restart xinetd with
/etc/init.d/xinetd restart